Optimización del rendimiento

• No utilice cachés compartidos para los núcleos del procesador de su controlador.

• Si está utilizando buses de campo basados en Ethernet para su dispositivo de destino, utilice un adaptador físico para ellos. No utilice una arquitectura de conmutador.

• Utilice un kernel en tiempo real.

  Recomendamos utilizar el kernel de preferencia RT (https://rt.wiki.kernel.org) para su sistema Linux. En el caso de las distribuciones Debian y Ubuntu, encontrará un kernel RT como paquete que puede instalar fácilmente usando el apt dominio. Para obtener detalles sobre esto, consulte el manual de su distribución.

  • En sistemas Debian

    sudo apt-get install linux-image-rt-amd64

  • Comprueba qué kernel estás usando con el uname -a dominio. Por ejemplo.

• Evite utilizar un administrador de ventanas, un servidor GUI/X o similar en su sistema.

  El uso de estas herramientas podría afectar las capacidades en tiempo real de su sistema, lo que resulta en una alta fluctuación en la aplicación IEC).

Uso de "herramientas rt":

• Instalación de "rt-tools": sudo apt install rt-tests

• Iniciando "prueba cíclica": sudo cyclictest -p 99 -t -m

• El man cyclictest El comando le muestra más opciones de línea de comandos que puede usar para medir mejor aspectos de rendimiento más específicos de su sistema.

• Desactive el modo de ahorro de energía de la CPU.

• Deshabilite el hiperproceso.

  Puede usar el siguiente comando para deshabilitar el hiperproceso (ejemplo):

  echo off | sudo tee /sys/devices/system/cpu/smt/control

• Deshabilite el escalado y cambio de frecuencia de la CPU tanto como sea posible.

  Por ejemplo, establezca la frecuencia mínima y máxima de la CPU en el mismo valor (fijo).

• Deshabilite el mecanismo de limitación en tiempo real del kernel de Linux, ya que esto puede provocar fluctuaciones en su sistema.

  Para obtener más información, consulte: The Linux Foundation: Programación: aceleración de RT

  Puedes usar el siguiente comando para deshabilitar la limitación en tiempo real (ejemplo):

  echo -1 > /proc/sys/kernel/sched_rt_runtime_us

• Verifique y cambie el gobernador de programación/escalado.

  • Verifique el gobernador de programación/escalado utilizado:

    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

  • Cambie el regulador de programación/escalado utilizado (como root/admin) a Performance:

    echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    # set it for all available cores:
    echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
    echo "performance" > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

    Tenga en cuenta que el regulador de escala debe restablecerse cada vez que se inicia el sistema. También puedes configurarlo mediante la configuración del kernel.

    El intel_pstate El controlador del kernel puede dificultar la configuración correcta. Por lo tanto, debes utilizar el cpufreq-info comando para verificar su configuración.

  • También puedes utilizar programas como cpu-freq-utils. Esto podría interferir con los controladores Intel pstate. Estos controladores normalmente requieren un enfoque diferente para configurar la frecuencia de la CPU.

  • Para más información, ver: https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt

• Desactivar HyperV en el BIOS (si está disponible).

• Cree una aplicación de prueba que describa aproximadamente la aplicación para la cual desea optimizar su sistema (en términos de recursos requeridos, rendimiento requerido y tamaño del proyecto).

• Puede hacer esto de forma iterativa: primero cree una aproximación muy aproximada y luego amplíela para acercarse cada vez más a la aplicación real.

• Mín. Jitter (μs) / Máx. Jitter (μs)

  • Los valores deben ser lo más cercanos posible a los valores determinados por el programa "cycletest". Los detalles se describen en la sección Configurando Linux.

  • Para obtener más información sobre la fluctuación y la latencia, consulte: Definiciones de fluctuación y latencia

  • Para obtener más información sobre la pestaña Monitoreo, consulte: Pestaña: Monitoreo

• Tiempo de ciclo promedio (μs) / Máx. Tiempo de ciclo (μs) Tiempo de ciclo (μs)

  • El ciclo máximo nunca debe acercarse al tiempo del ciclo configurado. Esto genera problemas tan pronto como el sistema experimenta una carga elevada.

  • Mantenga siempre el tiempo del ciclo lo más corto posible.

• Divida las tareas de larga duración en varias tareas más pequeñas.

• Cuando se ejecuta, el tiempo de ciclo máximo de la tarea de mayor prioridad nunca debe alcanzar el tiempo de ciclo configurado. Si no puede evitar esto, entonces debe aumentar el tiempo de ciclo configurado para asegurarse de que los tiempos de ejecución sean consistentes.

• Al iniciar sistemas de bus de campo (por ejemplo, EtherCAT o PROFINET), los ciclos de inicio pueden provocar una carga de CPU ligeramente mayor. En este caso, tiene sentido controlar la carga de la CPU poco después de iniciar la aplicación.

Las siguientes opciones no se pueden cambiar en CODESYS Virtual Control SL, pero debe configurarse en el host:

• Establecer el valor para DisableCpuDmaLatency a 1:

  [SysCpuHandling]
  Linux.DisableCpuDmaLatency=1

  • Tenga en cuenta que esta es la configuración predeterminada a partir de la versión de ejecución 4.11.0.0.

  • Para verificar su versión de tiempo de ejecución, haga clic en Extras → Actualizar Linux → Sistema → Información del sistema.

• Compruebe si realmente se está utilizando el kernel en tiempo real.

  • A partir de la versión 4.11.0.0, puede utilizar el comando de shell del PLC rt-get kernelinfo para comprobar esto.

  • Si tiene una versión anterior, puede hacerlo directamente en la línea de comando con el comando uname -a.

  • Si no se utiliza el kernel en tiempo real, deberá comenzar de nuevo desde el principio.

• Puedes utilizar las pruebas del paso anterior. Configuración del sistema de ejecución CODESYS para probar su aplicación IEC.

• Puedes usar el multinúcleo característica en CODESYS.

• Determine las prioridades correctas para sus tareas. Las tareas importantes deberían tener mayor prioridad.

  tabla 5. Mapeo de prioridades de tareas IEC y prioridades de subprocesos de Linux:

  Prioridad de tarea IEC	Prioridad de Linux
  --	88 (SCHED_FIFO)
  --	57 (SCHED_FIFO)
  0 (prioridad más alta en tiempo real)	56 (SCHED_FIFO)
  15 (prioridad más baja en tiempo real)	41 (SCHED_FIFO)
  16 (no prioridad en tiempo real)	0 (SCHED_OTHER)
  31 (no prioridad en tiempo real)	0 (SCHED_OTHER)
  --	0 (SCHED_OTHER)
  Aviso En un sistema Linux convencional, la mayoría de las interrupciones (IRQ) y los trabajadores del kernel tienen la prioridad 50 de Linux. Si se utilizan prioridades superiores (con una carga elevada), es posible que las funciones del sistema (red/almacenamiento) no

  
  
  

• Puede configurar la prioridad de una tarea en la configuración de tarea respectiva.

  

Si no logra el rendimiento deseado después de todos los pasos mencionados aquí, puede consultar las siguientes secciones:

• Información específica del bus de campo

• [Para expertos] – Herramientas y temas adicionales

• Comprobar el Send Time / Recv Time valores en la página de estado de EtherCAT.

  • Una CPU x64 con un procesador Intel Core i7 y un buen adaptador debería tener menos de 10 µs.

  • Los procesadores ARM con chip integrado tendrán ~50 µs o más.

  

• Comprobar el Send Time / Recv Time valores en la página de estado de PROFINET.

  • Una CPU x64 con un procesador Intel Core i7 y un buen adaptador debería tener menos de 10 µs.

  • Los procesadores ARM con chip integrado tendrán ~50 µs o más.

  

• Para ordenar sus prioridades y las IRQ requeridas, puede usar los comandos del shell del PLC irq-list y irq-set-prio.

  • Estos comandos utilizan las prioridades normales de Linux y no las prioridades IEC.

  • Esta optimización no es posible en CODESYS Virtual Control SL, sino más bien en el sistema anfitrión.

• Utilice un adaptador de red independiente para los dispositivos.

• Para más información, ver:

  • EtherCAT

  • PROFINET

  • Ethernet/IP

  • CANbus, CANopen

• KernelShark/rastreo del kernel

  • Este es el programa elegido si descubre que la causa de sus problemas de rendimiento tiene que ver con la programación. Con la ayuda del "rastreo del kernel", puede ver si su tarea está siendo interrumpida por otra tarea, otro servicio o una interrupción.

    • trace-cmd record -p function

    • Puede utilizar KernelShark para examinar el generado trace.dat archivo.

  • En general, los problemas de programación se pueden dividir en dos categorías:

    • Reemplazo / preferencia

      • Si la interrupción o la tarea que impide la ejecución es innecesaria, desactívela.

      • Aumenta la prioridad de tu tarea o reduce la prioridad de las demás.

      • Cambie a un núcleo de CPU diferente.

      Importante

      Compruebe la efectividad de los cambios utilizando los programas descritos en el capítulo anterior.

    • Tiempo de ejecución

      Ver a continuación: "Seguimiento de la función del kernel"

• Seguimiento de la función del kernel

  • Si determina que el tiempo de ejecución del código es demasiado alto, puede utilizar esta herramienta para identificar el problema.

  • Si la función con un tiempo de ejecución demasiado alto está en su propio código, entonces debe optimizarla.

  • Si la función con un tiempo de ejecución demasiado alto está en el kernel, entonces puede intentar lograr la funcionalidad deseada con otra función del kernel. Alternativamente, también puede pasar parámetros de configuración al controlador del kernel para reducir el tiempo de ejecución.

  • Si ninguna de estas opciones resuelve el problema, probablemente necesitará utilizar hardware más potente.

Fíjate en los siguientes puntos y comprueba si son o no la herramienta correcta para alcanzar tus objetivos de rendimiento:

• PREEMPT_FULL

• isolcpu

• rcu_nocbs

• rcu_nocb_poll

• nosoftlockup

• deshabilitar equilibrio irq

• kernel.sched_rt_runtime_us